A method for functional it analysis
The functional it analysis can be described using a theory designed by Talbert [2002]. She says that every ERP supplier has numerous assumptions about the way in which a business process should work.
Suppliers use these assumptions when designing and consecutively programming best practices into their ERP systems.
These best practices do not always mirror the true business processes of the organizations that implement ERP. Many case studies and other descriptions indicate that misfits, differences between the programmed best practice and the actual business process, are a substantial risk for the successful implementation of ERP [Grabski et al., 2003; Koning, 2004].
A good functional it analysis during the ex ante evaluation of ERP can mitigate the risk of misfits.
According to Talbert, organizations have four options to create a good it between their business processes and their ERP system.
The first option is process replication. When applying this option, organizations configure the ERP system in such a way that the existing business processes are duplicated or at best automated. When this option is followed in its extreme form, the ERP implementation will have limited impact on the business processes. It can be expected that the implementation will also have limited benefits, as process improvement is not achieved.
The second option is process modification. With this option, business processes are adapted in such a way that they it with the best practices that the ERP system has on offer. Process modification leads to business processes that are based on best practices, with the related benefits of standardization and process improvement. It also leads to changes in business processes that may impact the daily work of employees. When applying this option, organizations at least need to train the employees, and in a more extensive form process modification can lead to large-scale reorganizations. Outside of the ERP world, process modification is also known as business process redesign (or: BPR). Within the ERP world, process modification is also known as a no adaptations or plain vanilla approach.
The third option to create a good it between business processes and ERP is software modification. This option consists of the configuration, localization and adaptation of the ERP system in such a way that existing business processes are supported in the best possible way. The adaptations lead to company specific extension of the ERP system, which in turn will lead to extra costs and extra time-to-market when a new version of the ERP system is implemented. Adaptation is justified when it sustains an existing competitive advantage or creates more added value than an ERP system without adaptations.
The last option distinguished by Talbert is called exploration. This option differs from the three options mentioned above: it does not prescribe one functional it option for all business processes, but instead promotes a selection of the best option per business process. According to Talbert, exploration is the preferred option, because it offers the best balance between optimal business processes and the best practices an ERP system has on offer.
A side note to Talbert’s theory is in order. Talbert, as well as other authors in ERP, warns against the high costs, the long time-to-market and the decreasing legibility the come with software modification.
This warning was certainly justified for the early generations of ERP systems. Today, however, a more nuanced view is required.
Firstly, ERP systems have developed in the past few years in such a way that they support more and more business processes. Additionally, the available best practices have become more sophisticated. This implies that the need for software adaptation has decreased over the past decade.
Secondly, the design of modern ERP systems takes potential adaptations into account. The ERP systems have become modular, and have built-in connection points for adaptations. The high-end ERP systems make sure that these connection points remain intact when new versions are introduced. This reduces the time and effort organizational need to invest when they decide to upgrade their adapted ERP system to a newer version.
Finally, software modification s does not always have to be built by the organization itself. Functional extensions these days are also offered by partners of the ERP suppliers. The large ERP suppliers have worldwide networks of partners that offer solutions for specific organizational requirements [Oracle 2007b; SAP 2007]. Examples of these solutions are industry-specific production planning modules, reporting modules for catalogue printing, or financial consolidation tools. The partners take care of the seamless connection of their solution to the ERP system, not only for the current version, but also for future versions. These solutions mitigate the risks of adaptations to a large extent.
Summarizing, in modern ERP systems adaptations are required less frequently, and their impact on costs and legibility are less detrimental. The disadvantages of software modification nowadays are therefore smaller than in the past.